Subject: APPN DLUR-3d draft spec available

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Mon, 14 Mar 94 17:38:02 EST

The DLUR architecture document has been updated and is available by
anonymous FTP to ibmstandards.cary.ibm.com under the name of
aiw/sig/dlur/dlur3d.psbin - the file is a PostScript file, but treat it
as binary when you get it and print it.  There are also compressed
versions of the file (aiw/sig/dlur/dlur3d.zipbin and
aiw/sig/dlur/dlur3d.exebin).

The items added in DLUR-3d are:

** 1) added DLUR handling RSP(ACTLU) without a CV X'0C'

      David Matusow of Hypercom asked how a DLUR would handle
      a RSP(ACTLU) from a back-level node.  Investigation shows there
      are 3 possible RSP(ACTLU) formats for a DLUR to handle:

            - no CVs attached
            - CV X'00' attached
            - CV X'00' & CV X'0C' attached

      The architecture only specifically addresses the third case, and
      since part of the processing dictated by the architecture
      requires a DLUR to always set a bit in the CV X'0C', the
      architecture must also address the cases where RSP(ACTLU) is
      received without a CV X'0C'.

      Therefore, DLUR BF processing of RSP(ACTLU) will be updated to
      match the corresponding NCP BF processing:

         - if the RSP(ACTLU) includes a CV X'0C', continue processing
         - if the RSP(ACTLU) only includes a CV X'00', build a CV X'0C'
           and add it to the RU
         - if the RSP(ACTLU) has no CVs, build a CV X'00' and a CV X'0C'
           and add them to the RU
         - when building a CV X'00', set maximum RU size to 256 bytes
           and all other fields to 0
         - when building a CV X'0C', set secondary LU capability to
           enabled, LU-LU session limit to 1, SESSST support to 1 (part
           of new DLUR support), and all other fields to 0

** 2) clarified use of LU 6.2 BIS protocols for CP-SVR pipe

      Questions arose about the use of LU 6.2 BIS function in
      Figure 5-3 where the UNBIND was returned with a sense code.
      Current implementation uses BIS for normal UNBINDs but not for
      UNBINDs with a sense code.  The architecture document will be
      updated to reflect the implementation, removing the BIS reference
      in Figure 5-3 and specifying BIS use for normal UNBINDs in the
      pipe deactivation section.

** 3) update sense codes for DLUR when SSCP-PU/LU session inactive

      In a earlier draft sense codes were selected for use when data
      was received at the DLUR from the dependent LU or PU and the
      corresponding session with the SSCP was inactive.  These sense
      codes are different than those currently used; since this could
      result in changes to applications, the original sense codes will
      be used instead:

      a) When the DLUR receives SSCP-LU data from the SLU while the
         SSCP-LU session is inactive, the document indicates that a
         sense code of X'0857 0003' will be returned.  This will be
         corrected to state X'8005 0000' (no session).

      b) When the DLUR receives SSCP-PU data from the SLU's PU while
         the SSCP-PU session is inactive, the document indicates that a
         sense code of X'087C 0000' will be returned.  This will be
         corrected to state X'8005 0000' (no session).

** 4) updated CP-SVR pipe handling over limited resources

      Several questions have been raised by implementers about whether
      or not to allow CP-SVR pipes to use limited resources, and if
      they are allowed, whether or not to deactivate the pipe due to
      inactivity.

      The DLUR/S architecture already recommends against activating
      CP-SVR pipes over limited resources, and if activated anyway,
      indicates that the pipe should not be deactivated due to
      inactivity.  These points will be reemphasized in the following
      updated paragraph to be included in the architecture:

          In addition, DLUS and DLUR nodes will not UNBIND CPSVRMGR
          sessions when no conversation is currently allocated over
          the session.  In general, it is not recommended to BIND
          CPSVRMGR sessions over limited resources.  Limited resources
          are usually indicated as such so that they are used for
          short-lived connections.  CPSVRMGR sessions are long-lived
          connections which, if established over limited resources,
          could be very expensive.  Even so, CPSVRMGR sessions are
          permitted over limited resources; implementations may
          optionally choose to prohibit CPSVRMGR sessions over limited
          resources.  If a CPSVRMGR session is activated over a limited
          resource, the DLUS and DLUR nodes should ignore the limited
          resource characteristic of that session and not deactivate
          the session when the limited resource logic would normally
          dictate session deactivation due to inactivity.  In general,
          DLUS and DLUR nodes should not UNBIND a CPSVRMGR session
          (across a limited resource or not) unless one of the session
          deactivation conditions specified within "CP-SVR Pipe
          Deactivation" is encountered.

** 5) added another use of X'086C 5100' sense code at DLUR

      DLUR nodes currently send a negative RSP(ACTPU) with sense code
      X'086C 0051' when the ACTPU request is missing an expected
      CV X'51'.  A similar situation is currently not addressed in the
      architecture, where a DLUR receives a RSP(REQACTPU) which is
      missing an expected CV X'51'.

      When a DLUR node receives a RSP(REQACTPU) which is missing an
      expected CV X'51', it has no vehicle at that moment to indicate
      the error.  Therefore, it will wait for the ensuing corresponding
      ACTPU request and reject it with a X'086C 0051' sense code.

** 6) updated DLUR/S multi-subnet support

      While reviewing the most recent version of DLUR/S multi-subnet
      support, several concerns were raised:

      a) requiring all EN DLURs to register their TGVs wastes DLUS
         storage, since tail vectors from EN DLURs not in the same
         subnet as the DLUS are not used in route calculation

      b) multi-subnet configuration restrictions involving subarea
         networks do not take VR TGs into account

      c) multi-subnet configuration restrictions should be summarized
         from a particular subnet's viewpoint

      The following items are proposed to address the respective
      concerns:

      a) Only EN DLURs in the same subnet as the DLUS will transmit
         their TGVs to the DLUR.

      b) CP-SVR pipes must not pass through a subarea network unless
         they use a VR TG.

      c) Configuration Restriction Summary:

         - traffic entering and leaving the DLUS subnet must go through
           an EBN at the DLUS subnet boundary
         - traffic entering and leaving the PLU subnet must go through
           an EBN at the PLU subnet boundary
         - traffic entering and leaving the DLUR subnet must go through
           an EBN or an R1BN or a NN at the DLUR subnet boundary

** 7) added DLUR building XID format 0 for external PUs which do not
      support XID

      In reviewing the DLUR/S architecture, a reviewer from Metaplex
      pointed out that the DLUR will build an XID format 0 only for
      internal PUs.  However, there are external PUs which do not
      support XIDs and which need the DLUR to build an XID format 0 for
      them.

      The DLUR/S architecture will be updated to indicate that a DLUR
      will build an XID format 0 for an internal PU as well as an
      external PU which does support XID.

** 8) added DLUR zeroing out ACTLU indicators

      A problem was reported where ACTLU was processed by DLUR and
      passed on to the LU which rejected the request.  Investigation
      showed indicator bits on in the ACTLU which the LU did not
      recognize.  There is nothing currently in the architecture to
      handle non-zero indicator bits other than the type activation
      requested field.

      The DLUR will zero out all indicators (ACTLU RU byte 1) except
      the type activation requested field (bits 6-7).  Other indicators
      have been defined (and appear in the licensed formats) for use by
      the NCP BF and are not recognized by the LU; the NCP BF zeroes
      out these indicators and so will the DLUR.

I'm requesting comments on these items to be received no later than
March 29.  If there is a consensus for approval at that time, I will
consider these items to be at AD status as of March 30.

The internals chapter continues to be deferred as problems continue to
appear (I won't be surprised if there is a DLUR-3e before the DLUR-4
draft with the internals).  I've just received the second internals
draft from Data Connection and need to convert it into BookMaster next.

Ed Tremblay